NameNode掛掉之後，基本上整個Hadoop就往生了...
如果NameNode資料沒遺失的話，那重啟應該就沒問題，但是...
當edits與fsimage遭遇不測的時候...HDFS上的資料基本上就要說掰掰了...

為了讓Hadoop能存活下去，於是Hadoop的HA就開始發展了...
據我所知一開始HA好像是FaceBook有先釋出patch還有作法，
後來也有人使用Linux 結合heartbeat與DRBD來DIY NameNode的HA。
可參考這個網址
https://www.facebook.com/note.php?note_id=106157472002
DRBD主要就是讓兩台namenode的磁區和內容同步，很像透過網路的方式來做raid-1，所以網路速度很重要...

首先，先來看看Facebook的HADOOP的SPOF解法，來源網址為
https://www.facebook.com/notes/facebook-engineering/under-the-hood-hadoop-distributed-filesystem-reliability-with-namenode-and-avata/10150888759153920

附帶一提，Secondary namenode並不是HA的解法，它的作用是為了協助Namenode進行edits與fsimage的merge，讓重啟的時候Namenood不會因為跑edits的檔案太多，以致於執行的時間很長。不過當namenode有問題的時候，從secondary namenode載入metadata，也是可行的，但是還是要人工介入且也不是HA。

Facebook的HA解決方案
Avatarnode: A working solution for Namenode failover

FB把Namenode取名叫做阿凡達node哈，基本上是Primary(active)-standby架構，就是一個服務的時候，另外一個不會進行服務，Client端會透過Zookeeper知道哪個avaternode是存活的。

Avaternode的概念是，datanode會同時將block的資訊給兩個avaternode，但是Client再進行操作的時候，只會對active那台做操作，另一台standy則會透過共同的NFS來取得最新的metadata資料。
當active那台有問題的時候，ZK就會將client導到standby那台，這個時候因為standby還是有最新的資訊，就可以繼續服務。

接著是Cloudera的HA解決方案
http://blog.cloudera.com/blog/2012/03/high-availability-for-the-hadoop-distributed-file-system-hdfs/
High Availability for the Hadoop Distributed File System (HDFS)

基本上跟FB的做法很類似，也是中間透過一個NFS來存放Metadata的資訊，不過之前我們在使用這個版本的HA時，曾經發生兩個namenode和NFS上的metadata資訊都不一樣，最後是把三個metadata一一比對，然後修正seen_txid的數字，才將Hdfs救回，主要是因為active的namenode已經不能服務，但是沒死透，變成兩個namenode都對NFS做操作。

不過後來Cloudera有持續對HADOOP的HA做加強，原本的Hadoop在2.0的時候也針對namenode在越來越多檔案的時候，namenode上的index會過多，所以有HDFS Federation的概念。

這是cloudera的HA指南
http://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH4/4.2.0/PDF/CDH4-High-Availability-Guide.pdf

如果想更深入了解Hadoop 2.0的HA與Federation也可以參考這篇文章
http://www.sizeofvoid.net/hadoop-2-0-namenode-ha-federation-practice-zh/